LGTM. Verified that createServerClient() delegates to createServiceRoleClient(), so the cache: 'no-store' fix correctly applies to homepage queries. Root cause analysis is sound — Next.js Data Cache intercepting Supabase's internal fetch() calls. The page-level revalidate still handles HTML caching appropriately.

Verdict: REQUEST CHANGES

Summary

The proposed cache bypass is too broad. It fixes the filtered home-page read by making every service-role Supabase fetch uncached, which changes caching behavior across much more of the app than this ticket scoped.

Findings

• [high] cache: 'no-store' is being added to the shared service-role client factory, so every createServerClient() consumer inherits uncached fetches. In Next.js, an uncached fetch opts the route out of the Full Route Cache, so this does not just fix the live language-filter query. It also makes pages like the home feed, story pages, OG routes, and any other server-side reads that use createServerClient() render dynamically on every request, defeating the existing revalidate behavior and creating a broad perf regression.
  • File: lib/supabase.ts:28
  • Suggestion: Scope the cache bypass to the specific read path that was observed stale on the live site, or invalidate/revalidate the affected route/data after the migration, rather than changing the shared client factory for the whole app.

Decision

Request changes until the cache bypass is narrowed so it does not disable route caching for every server-side Supabase read.

Verdict: REQUEST CHANGES

Summary

This narrows the change to the homepage, but it still does not appear to change the caching semantics for the affected query path.

Findings

• [high] await connection() is being added before the Supabase query, but this page was already reading the request-time searchParams prop before issuing that query. In Next.js, fetches after request-time APIs are already treated as uncached by default, so this change is likely redundant and may not actually fix the stale-English-filter bug seen on the live site.
  • File: src/app/page.tsx:21
  • Suggestion: Either show a concrete repro proving connection() changes the live behavior here, or target the actual stale layer directly (for example by making the relevant data fetch explicit about cache behavior instead of changing route rendering semantics).

Decision

Request changes until there is evidence this change affects the stale query path, or the fix is moved to the specific data-fetch layer causing the bug.

Verdict: REQUEST CHANGES

Summary

This narrows the diff to a single line, but the proposed fix still does not appear to affect the stale layer for this route.

Findings

• [high] Removing export const revalidate = 120 from the homepage is likely a no-op here. This page already uses the Page searchParams prop, which Next.js treats as a Dynamic API that opts the route into request-time rendering. Next.js also does not cache fetches discovered after a Dynamic API is used. Given that the Supabase query runs after await searchParams, the stale-English-filter bug is unlikely to be caused by this route-level revalidate export.
  • File: src/app/page.tsx:7
  • Suggestion: Show a concrete live repro proving that deleting revalidate changes the behavior on this page, or move the fix to the actual stale layer instead of changing a route setting that should already be bypassed by the page's dynamic searchParams usage.

Decision

Request changes until the fix targets a cache layer that is demonstrably involved in the stale live-site behavior.

Verdict: REQUEST CHANGES

Summary

The branch is now minimal, but I still do not see evidence that deleting the homepage revalidate export changes the stale layer involved in this bug.

Findings

• [high] src/app/page.tsx already uses the Page searchParams prop, which Next.js documents as a Dynamic API that opts the page into request-time rendering. Next.js also documents that fetch requests discovered after a Dynamic API are not cached by default. Since the Supabase read happens after await searchParams, removing export const revalidate = 120 still looks unlikely to affect the stale English-filter behavior on the live site.
  • File: src/app/page.tsx:7
  • Suggestion: Show a concrete repro that this line removal changes the live behavior, or move the fix to the specific cache/data layer that is demonstrably serving stale results.

Decision

Request changes until the fix targets a cache layer that is actually implicated by the live-site bug.